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^ (57) Abstract: A method and system for aggregating, analyzing, and reporting on the client financial information from multiple 
financial service providers. Client financial data is aggregated from a variety of sources and organized in a hierarchical structure 
to reflect different levels of information and the relationship between the data. The aggregated client financial data is stored in a 
consolidation database, which for example, may be centralized or distributed database. A reconciliation procedure rechecks the 
c ijent financial data to determine if any discrepancies exists at the source financial service provider. The reconciliation procedure 
2j also keeps the aggregated data in the consolidation database synchronized with the client financial data maintained by the source 
^ financial service providers. Analyses are performed on the aggregated client financial data. The analyses may be performed uni- 
versally across all of a client's financial data retrieved from the source financial service providers. Analyses include among others 
performance analysis, risk analysis, portfolio analysis, compliance rule adherence, and relationship management. An accounting 
Q module maintains general ledger and other accounting information for the aggregated client financial data. Reporting and querying 
^ modules provide the client with either electronic access to the data and the results of the analyses or a printed report sent to the client 
^ by means of traditional mail. 
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METHOD AND SYSTEM FOR FINANCIAL 
DATA AGGREGATION, ANALYSIS AND REPORTING 

FIELD OF THE INVENTION 

The present invention relates to aggregating financial data, esta blishing a relationship 
structure between the data, analyzing the aggregated financial data and reporting on the 
aggregated financial data and related analyses. 

BACKGROUND INFORMATION 

The Internet and the World Wide Web (the "Web") have become an integral means of 
communication within our society. Individuals^ corporations, churches, political 
organizations and others use the Web to post their information so that interested parties may 
find and peruse it Commercial entities also use the Web to provide services or void their 
wares to existing and potential clients. These commercial entities provide their goods and 
services by maintaining a presence on the Web through their Web sites, that contain one or 
more Web pages, each a window of information. One subset of commercial entities with a 
presence on the Web are financial service providers. 

Financial service providers use the Web to provide their clients with direct access to 
their accounts as well as certain additional services. However, most financial service 
providers do not aggregate data from several institutions into a single, clear presentation for 
their clients. Such a presentation simplifies a client's oversight of their financial assets and 
liabilities as well as providing more comprehensive reporting. The ability to aggregate data 
from several sources into a single consolidated presentation is a highly desirable service 
especially for busy clients or clients with complex financial holdings and dealings such as 
high net worth individuals and families. Whether the presentation of the aggregated- data is— 
electronic, such as a Web page, or printed, such as a printed summary sent via traditional 
mail, a clear benefit exists for the client Providing Web based presentation of such 
information is particularly advantageous due to the real-time or near real-time accuracy and 
updating of the data and the client convenience of being able to access the information at any 
time. 

Several firms have tried to address this shortcoming in the services provided by 
financial service providers by marketing aggregation services. Companies such as Yodlee 



WO 02/19229 P^piSOl/27283 

(yodlee.com), OnMoney (onmoney.com) and VerticalOne (verticalone.com) provide data 
aggregation services to both financial service providers and individual clients. These 
companies obtain their information from detailed screen-scraping of -Web based information 
sources. Screen-scraping is the use of a client's login and password to access a Web site and 
capture the information displayed on the screen. The data is garnered from several sources, 
reformatted and displayed on a single Web page. The resulting Web page is displayed to an 
individual client either directly by the firm providing the data aggregation service (i.e., 
Yodlee, OnMoney or VerticalOne) or is presented through a licensed distributor Web site 
such as a Web site of a financial service provider. These data aggregation companies cover a 
diverse range of source data to be aggregated, often including non-financial information, but 
lack depth in their aggregation by not adequately addressing the complexity of the 
relationships and structure of the client data. In other words, currently existing data 
aggregation companies address the needs of clients with simple financial portfolios but do not 
address the complex needs of high net worth individuals and families. 

FIG. 4a illustrates one example of subscriber information retrieved from screen- 
scraping and the lack of relationships between and a hierarchy in the data retrieved by a data 
aggregation company. A subscriber 401 is the client who directly or mdirectly through a 
licensed distributor Web site engages the services of the data aggregation company. The 
subscriber 401 is directly linked to his/her assets and liabilities such as a brokerage account 
402, asset management account 403, money market account 404, bank accounts 405, credit 
card accounts 406, and frequent flyer program 407 illustrated by the example in FIG. 4a The 
relationships between the subscriber, his/her assets, and tiabilities gathered through screen- 
scraping and displayed by existing data aggregation companies lack the complexity necessary 
to reflect the intricacies in the relationships and hierarchical structure prevalent in the 
financial data of high net worth individuals and families. 

High net worth individuals and families often have complex interrelationships 
involving their financial assets and liabilities. These interrelationships involve a structure and 
a hierarchy between individuals, families, business associates (such as partners), investment 
accounts/portfolios, other financial assets, financial liabilities, trusts, companies, and 
beneficiaries. The previously mentioned data aggregation companies do not provide services 
adequately reflecting these interrelationships because they neither account for nor track these 
relationships. Also, the screen-scraping method of obtaining data inputs is not adequate for 
retrieving the information needed by high net worth individuals and families. Further 
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limiting the effectiveness of the data aggregation companies in dealing with high net worth 
individuals and families is the lack of value added services performed on the aggregated data. 
Value added services such as risk analysis that are performed for client accounts at a financial 
service provider are even more relevant and important for the aggregation of an individual's 
or family's holdings. Unfortunately, the data aggregation company do not take advantage of 
the data aggregation to provide the value added services that high net worth individuals and 
families are accustomed to for their holdings at a financial service provider. The present 
invention addresses and solves these problems by providing a method for aggregating 
financial data, building relationships and a structure among the information gathered, 
performing value added services and analyses on the aggregated data, and presenting, for 
example, high net worm individuals and families a myriad of reporting options that 
adequately address their needs. . . 



SUMMARY O F THE INVENTION 

The present invention relates to aggregating data from multiple financial service 
providers, building appropriate relationships and a hierarchical structure among the 
aggregated data, storing the data in one or more databases, reconciling the data, performing 
analyses on the data, providing value added services on the data, and providing numerous 
reporting options to the client Clients may interact directly with the Web site of the 
commercial entity operating the present invention or they can interact with the commercial 
entity operating the present invention through a licensed distributor's Web site, such as a 
financial service provider's Web site, that is seamlessly integrated with the commercial entity 
operating the present invention. 

The present invention delivers aggregated account and product information to clients 
over an information network and through statements delivered through traditional mail. This 
is achieved through a database, such as a centralized or distributed database, consolidating 
client information, data aggregation, and relationship structure management Data is 
aggregated from multiple sources using data feeds from the financial service providers 
wherever possible. Data may also be provided through direct data entry by the client or 
authorized agent of the client such as the financial service provider and may be entered 
directly by the commercial entity operating the present invention's staff when received in 
electronic or print format from the client or authorized agents. Screen-scraping may also be 
performed to obtain the necessary client financial information. Financial service providers 
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may include, for example, financial institutions that manage or handle a clients assets and/or 
liabilities as well as financial information providers such as a financial news service or a 
financial quote provider such as a brokerage that provides current stock quotes that can be 
used in determining the current market value of a security. 
5 During the data aggregation process, the client financial information is organized in a 

hierarchy based first on the subscriber, second based on entity (also termed "participating 
owner"), third based on account or legal entity (legal entity is also termed "holding entity"), 
then by asset or liability and position. The subscriber is the client for whom the financial data 
is being maintained by the commercial entity operating the present invention. An entity may 
10 be, for example, an individual or legal entity for whom information is tracked. The entities 
may be, for example, either individuals (founder, wife, and children) who make up the family 
of a subscriber or legal entities (e.g., family trusts and partnership entities).-Entities may be - 
linked to other entities or directly to accounts which in turn contain positions for various 
assets and liabilities. This structure and relationship information is determined from the 
15 client financial information or is provided by the client The data hierarchy and the 
relationships impose a structure on the received data assisting in its aggregation and 
organization. The received client financial information is stored in a consolidation 
databases) according to the data structure. 

Core and value added services are performed on the aggregated client financial data. 
20 Accounting records are kept by the accounting module, compliance rules are kept and the 
data monitored for adherence to these rule, the relationship structure is established, 
maintained and updated, while various analyses are performed on the data. The analyses 
performed can-include, for example, performance analysis, risk analysis, and portfolio 
analysis and involve a universal analysis approach versus a local approach. A universal 
25 analysis approach is one where the analysis is performed on data from multiple financial 
service providers (i.e., across all the client's financial service providers) and is more 
advantageous than a local approach where the analysis is performed only on the assets under 
management at a particular financial service provider. These various services and analyses 
may result in the generation of additional data which is stored in the results depository 
30 databases). The reporting module uses the data in the consolidation database(s) andrthe 

results depository databases) to present data to the client in various ways. Clients can have 
different views of the data based on the scope of access they have been given. 

According to an example embodiment of the present invention, a user interface such 
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as a graphical user interface (GUI) may query the databases through the querying services. 
The reporting module may work with the querying services and the graphical user interface to 
provide the client with pre-formalted or customized data presentation. Reporting can be done 
online over an information network or may be done through printed statements sent via 
traditional mail. 

A subscriber management system may also be used to track additional information 
about the subscriber including, in particular, information on what data the subscriber is 
granted permission to access. This permission-based access control is a conventional method 
of access control for database management systems. The permission-based access control 
may also be supplemented by a token-based access control and authorization system. 

The present invention provides clients, for example, the ability to review their 
aggregate holdings via easy to use statements that are globally accessible over an information 
network such as the internet. Clients may see their entire relationship structure as a cohesive 
whole and also see their aggregated holdings within that relationship. The consolidation 
database of the present invention serves as the hub around which clients may view their total 
net worth. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a network architecture that illustrates the relationship 
between the Internet, a data consolidation network node, Web users, and financial service 
providers according to one embodiment of the present invention. 

FIG. 2 is a block diagram illustrating a generalized flow of information -and 
processing performed by the data consolidation network node according to one embodiment 
of the present invention. 

FIG. 3 a illustrates a subscriber table in the consolidation database according to one 
embodiment of the present invention. 

FIG. 3b illustrates an entity table in the consolidation database according to one 
embodiment of the present invention. 

FIG. 3c illustrates an entity relationship table in the consolidation database according 
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to one embodiment of the present invention. 

FIG. 3d illustrates an account table in the consolidation database according to one 
embodiment of the present invention. 

FIG. 3e illustrates an legal entity table in the consolidation database according to one 
embodiment of the present invention. 

FIG. 3f is a block diagram illustrating the asset/liability table according to one 
1 0 embodiment of the present invention. 

FIG. 3g is a block diagram illustrating the position table according to one embodiment 
of the present invention. 

15 FIG. 3h is a block diagram illustrating the transactions table according to one 

embodiment of the present invention. 

FIG. 4a illustrates one example of subscriber information retrieved from screen- 
scraping and the lack of relationships between and a hierarchy in the data retrieved by a data 
20 aggregation company. 

FIG. 4b illustrates a subscriber as a whole with all its subordinate entities and entity 
relationships according to one embodiment of the.presentinvention.. 

25 FIG. 5a is a flowchart depicting the sequence of events that take place during the 

process of setting up a new subscriber account according to one embodiment of the present 
invention. 

FIG. 5b is a flowchart depicting the steps involved in the initial set-up of subscriber 
30 information according to one embodiment of the present invention. 

FIG. 5c is a block diagram illustrating the steps in defining the relationship structure 
between the participating owners according to one embodiment of the present invention. 
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FIG. 5d is a block diagram illustrating a sample relationship structure for a subscriber. 

FIG. 6 is a block diagram-illustrating how reporting view may be granted according to 
the defined scope of access according to one embodiment of the present invention. 

DFTAIff JED DESCRIPTION 

Although the embodiments described herein utilize the Internet and the World Wide 
Web (the "Web"), the present invention is compatible with other types of information 
networks (both public and private), and thus the embodiments described herein are not 
intended to limit the scope of the claims appended hereto. For example, the present invention 
may be implemented using a private Intranet, local area network (LAN), metropolitan area 
network (MAN), wide area network (WAN), dedicated or direct connections, and a wireless 
network. 

FIG. 1 is a block diagram of a network architecture that illustrates the relationship 
between the Internet, a data consolidation network node, clients, and financial service 
providers according to one embodiment of the present invention. Data consolidation network 
node 100 connects with financial service provider 190 network node to retrieve client data. 
Data consolidation network node 100 aggregates client data from the one or more databases 
195 at each financial service provider 190 consolidating the retrieved information into a 
consolidation database(s) 1 70 (an example of which is shown) at the data consolidation 
network node 100. Relationships among the client data are established resulting in an 
information hierarchy based on a subscriber as the topmost entity (subscribers are discussed 
in more detail below). Subscriber information is generated and stored in a subscriber 
database(s) termed the Subscriber Management System ("SMS") (not shown in FIG. 1). The 
client data in the consolidation database(s) 170 is analyzed and services are performed on the 
data with the results being stored in a results depository database(s) 171 . The SMS database 
and the results depository database(s) 171 may be, either together or individually, subsets of 
(or additional tables in) the consolidation database(s) and do not necessarily have to be 
separate. The data in the SMS database, the results depository database(s) 171, and the 
consolidation database(s) 170 at the data consolidation network node 100 are available for, 
inter alia, querying of data by the client, report generation, and user interface purposes. 

Clients 1 10a- 1 10c communicate with data consolidation network node 100 via one or 
more networks such as the Internet 105. In the embodiment depicted in FIG. 1; data 
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consolidation network node 100 is coupled to the Internet 105 via Tl line 130a. Client 1 10a 
illustrates a typical narrowband Web user connected to the Internet 105 via a dial-up 
connection described in more detail below- Client 1 10b illustrates a typical broadband Web 
user coupled to the Internet 105 via a cable modem 1 12b. Client 1 10c illustrates corporate 
5 Web users that are coupled to the Internet 105 via Tl line 130c and server 141a respectively. 
Corporate Web user 1 10c includes three network nodes 145a- 145c that share bandwidth on 
die local Ethernet network 142. Although FIG. 1 illustrates three clients 1 10a-l 10c, it is to be 
understood that data consolidation network node 100 may serve any arbitrary number of 
clients. 

10 In the example embodiment, client 1 10a utilizes personal computer 1 1 la to navigate 

the Web 1 05 via browser software and a display device. The browser software permits 
navigation between various file servers connected to the Internet 105, including gateway 
server 150a at data consolidation network node 100. The browser software also provides 
functionality for the rendering of files distributed over the Internet (i.e., through plugins or 

15 ActiveX controls). 

Client 1 1 0b is coupled to the Internet 1 05 via a broadband cable connection. In 
particular, personal computer 111b transmits packets via cable modem 1 12b to ISP 1 15b 
where the packets are routed over the Internet 105 to gateway server 150a. Packets from data 
consolidation network nodelOO traverse a reverse path to user 1 10b. Similar to client 1 10a, 

20 client 1 1 0b utilizes browser software to navigate the Internet 1 05 and the Web. 

Client 1 10c includes network nodes 145a-145c, which are coupled to the Internet 105 
via local Ethernet network 142, server 141a, and Tl line 130c of corporate user 1 10c. 
Network nodes 145a- 145c may communicate with data. consolidation network node 100 via 
local Ethernet network 142, server 141a, Tl line 130c, Internet 105, and Tl line 130a. 

25 Similar to clients 1 10a-l 10b, it is assumed that users at network nodes 145a-145c utilize 
browser software to navigate the Internet 105 and the Web. 

The specific nature of clients 1 10a-l 10c and the methods through which they are 
coupled to the Internet 105 depicted in FIG. 1 are merely exemplary. The present invention is 
compatible with any type of Internet client and/or connection (for example, broadband or 

30 narrowband). In general, it is to be understood that clients 110 may connect to the Internet 

105 using any potential medium whether it be a dedicated connection such as a cable modem, 
Tl line, DSL ("Digital Subscriber Line*'), a regular dial-up POTS ("Plain Old Telephone 
System") connection or even a wireless connection. Clients 1 10a-l 10c use the Web and the 
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Internet to connect with the data consolidation network node 1 00. 

The data consolidation network node 100 can be a node different from and separate of 
a financial service provider network node 1 90 when a separate commercial entity is 
implementing one embodiment of the present invention. The data consolidation network 
5 node 100 can also belong to a financial service provider either being a part of the financial 
service provider network node 190 or being a separate node run in conjunction with the 
financial service provider network node 1 90 according to another embodiment of the present 
invention. The example embodiments discussed below refers to the former situation where 
the data consolidation network node 1 00 is run by a separate commercial entity and is not part 

10 of a financial service provider network node 190. 

The distinction between a data consolidation network node 100 operated by a separate 
commercial entity and one operated by a financial service provider differs from the previously 
mentioned situation where fee data consolidation network node 100 is operated by a separate 
commercial entity but it is accessed either by a Web site presented by a licensed distributor or 

15 by a Web site presented by the separate commercial entity. In one case, the entire data 

consolidation network node 100 operation is discussed while the other merely references how 
a client 1 10a- 1 10c accesses the data consolidation network node 100. 



Data Sources 



FIG. 2 is a block diagram illustrating a generalized flow of information and 
processing performed by the data consolidation network node 100 according to one 
embodiment of the present invention-- The present invention aggregates client-data from a 
number of sources, e.g., financial service providers 200. For example, client bank account 

25 and loan data is retrieved from banks 201 while various annuity and life insurance 

information may come from insurance companies 204. Brokers and dealers 202 are another 
source of financial information as are investment and mutual fund managers 203 . 

The example financial service providers 200 mentioned are a small subset of the 
possible sources of information for the present invention. For this reason, a box for other 

30 financial service providers 205 is also included in the block diagram. Other financial service 
providers 205 may include, for example, sources covering a more diverse range of 
information that can help determine wealth, assets, and liabilities of the client Such diverse 
sources can include administrators of trusts, real estate investment trusts (REITs), account 
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custodians, and partnership information. The aggregated data 210 section of FIG. 2 lists other 
assets 215, 220 and liabilities 225 about which information is obtained from financial service 
providers 200. Additionally, other embodiments of me present invention may include 
nontraditional sources of information such as affinity programs, e.g., airline frequent flier 
miles. 

Data Acquisition 

In accordance with the example embodiment of the present invention, client data is 
received from sources external to the data consolidation network node 100. The data is then 
validated, and it is prepared for incorporation into the various components of the present 
invention. According to one embodiment of the present invention, the data acquisition 
process begins with the establishment of a relationship between an operator of the data 
consolidation network node 100 and a financial service provider 190 or other source of 
external data wherein the data structures, formats, and data acquisition protocols are 
specified. For example, XML (extensible Markup Language) may be used for the data 
exchange protocol. The data acquisition process ends, according to one embodiment of the 
present invention, with receiving, validating, and preparing the data in files so that it is in the 
appropriate format for use by the various component elements of the present invention. 

The first step in the data acquisition process according to one embodiment of the 
present invention is to establish a data acquisition relationship. A data acquisition 
relationship is established between the operator of the data consolidation network node 100 
("operator") and the financial .service provider, or other external data source by an agreement 
that the data source will provide the operator information concerning individuals' accounts 
associated with a subscriber. The relationship agreement may also identify the types of 
information to be transmitted, the format of the data, the data delivery mechanism, and the 
frequency of data delivery. Additionally, the agreement may also identify a point or points of 
contact for the resolution of problems that may arise. According to one embodiment of the 
present invention, the process of establishing data acquisition relationships is performed by 
the operator's staff after a client (e.g., a subscriber) has authorized the operator to obtain such 
information. For example, the process whereby a user becomes a client of the operator may 
include a form (either electronic or printed) granting this authorization and that, once 
completed, provides the necessary authorization thus beginning the data acquisition process. 
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The operator may also identify the data elements and their formats that are needed for 
consolidation with the present invention data according to one embodiment of the present 
invention. The operator may prepare and submit to the data sources different specifications 
for different data file types incl uding files for client information, account position 
5 information, transactions, and other activities according to one embodiment of the present 
invention. Additionally, the operator may also submit to the data sources code tables to be 
used with code conversion and formatting. For example, transaction codes, currency codes, 
country codes, bank product codes may also be code tables that are transmitted to the data 
source. The financial service providers or other data sources may then determine whether 

10 they can provide data to the requested specification and using the given codes. If the data 
source can't provide the data to the requested specification, the data source may provide the 
information using the formats available to the data source according to one embodiment of 
the present invention. The data source may provide data using die operator codes provided in 
the code tables sent to the data source or the data source may use their own codes. If the data 

1 5 source uses their own codes, the data source may also provide translation tables to convert 
their codes into the operator codes. If these translation tables are not provided, the operator 
may need to generate translation tables to assist in receiving and preparing the data from die 
data source. 

As part of the data acquisition process, the operator and the data source may establish 
20 a schedule for the transmission of subscriber data and the mechanism by which die data is 
submitted according to one embodiment of the present invention. For example, the 
mechanism for data submission may include the medium used (i.e., electronic or hard copy 
printout), n*"nm g . conventions, file location* format of 4h& submission (i.e., email attachment, 
FTP, floppy disk), and encryption keys and devices if the data is to be transferred encrypted 
25 The frequency of transfer and the time of day of transfer are two examples of scheduling 
information. 

One embodiment of the present invention may use data mapping and reformatting 
templates or scripts to convert the data from the external source into a format acceptable to 
the operator. For example, data mapping and transformation may involve code conversion, 
30 format conversions, and data type conversions. The data mapping schemes and reformatting 
scripts may be stored and maintain for use with other periodical data transmissions from the 
same or different external data sources. Test data may also be established, stored, and used to 
test the data formatting and transformation features of the system. The test data may also be 
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stored and maintained to periodically test data mapping schemes and formatting scripts when 

changes are made to mem. 

According to one embodiment of the present invention, data may be received, 
downloaded, or extracted from a data source as specified in the agreement The data once 
received, downloaded, or extracted using the mechanism and format in the agreement may be 
pre-processed in order to validate the integrity and completeness of the data prior to 
reformatting and restructuring the data. A temporary data store may be used to store the 
information validated during the pre-processing. Processing of the validated data may 
include the reformatting of the data according to a temple or script in order to bring the data 
into a similar format as the data stored by the present invention. If there are error in the 
processing (formatting) of the data received, the rejected records or those with errors mat 
have occurred due to the processing may be tagged or placed in a separate data store until the 
problem with the data can be addressed. The problems with these records may be resolved by 
calling the contact person at tile transmitting institution and having the data source resend 
updated information. Errors in the formatting of records or rows may also be resolved by 
filling in blank or missing data with a default data. Manual entry of the data by the operator's 
staff including the manual conversion of codes may also be performed. The data acquisition 
agreement, according to one embodiment of the present invention, may also include control 
measures and reconciliation methods in order to guarantee the completeness and correctness 
of the data. For example, control fields with certain values can be added to the data 
transmitted and the sum of these control fields may be checked against a control value where 
bom the sum and the control value should be the same. If an input file from the data source 
does not reconcile,. it may be very difficult to have the present invention data reconcile with 
the accounts at the data source. 

The acquisition of subscriber (client) data from external sources of data such as 
financial service providers may be performed by agreement between the data source and the 
operator. This agreement establishes the data feed, the manner and format by which the 
present invention receives the subscriber financial information. 

Data Feeds v. Screen-Scraping 

Once data acquisition relationships are established, data feeds may be established. 
One example embodiment of a data feed is the electronic transmission over the information 
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network of a client's financial information on a daily basis (each business day) where the data 
feed is initiated by an automatically executed batch program at the data aggregation network 
node 100. Data feeds are generally electronic because of the particularly advantageous nature 
of receiving data in this manner, however, the data feed can be in a printed format which is 
men manually entered or even scanned using OCR (optical character recognition software) at 
the data aggregation network node 100 according to an alternative embodiment of the present 
invention. In one embodiment of me present invention, the way the data feed is established 
(e.g., Tl links, dial-up, email, etc.), how the data feed may operate (e.g., frequency of data 
feed) and the format of the data provided may be standardized across the appropriate financial 
service provider nodes or may be tailored for one or all of the financial service provider 
nodes. 

Data feeds are different from screen-scraping because they provide greater and more 
consistent information. This difference may be important in accurately reflecting the net 
worth of individuals and families, for example. Data feeds may also be necessary to properly 
construct the relationships and hierarchy among the client's financial information. For 
example, screen-scraping is limited to the information displayed on the financial service 
provider network node Web site and is also limited by the format in which the information is 
presented. Data feeds do not have this limitation because they provide a more complete set of 
information that is already in a format usable by the data aggregation network node 100. 

Data Aggregation 

Client financial data received via data feeds from multiple .financial service providers 
200 may be consolidated and also organized 210. A protocol mapping process of the present 
invention organizes the retrieved data into the appropriate categories (such as subscriber, 
participating owner, legal entity) so that it can be stored in the consolidation database 230. In 
an advantageous embodiment of the present invention, the operator may provide a data 
interface to the financial service provider which includes predefined category designators for 
the financial service provider to select from in determining the appropriate category of the 
client data. An alternative embodiment of the present invention involves a determination 
made automatically by the system as to the appropriate category according to the data 
acquisition agreement and/or a number of parameters. In the alternative embodiment, if the 
data can not be automatically categorized, exceptions are stored in an exceptions queue which 
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may be manually reviewed by the operator staff and the necessary adjustments made to the 
automatic data category selection routines so that this information may be automatically 



protocol mapping process is a manual process whereby the information is received either 
electronically via a data feed or in a hard copy format and the operator staff manually 
determine the category in which the data belongs. The protocol mapping process aggregates 
the data by category (if known) according to one embodiment of the present invention. One 
category of aggregated data is securitized assets 215 that include, among others 219, traded 
equity 216 such as stocks, fixed income instruments 217 such as bonds, and funds 218 such 
as investment management funds or mutual funds. Nonsecuritized assets 220 is another 
aggregation category and include, among others 224, real estate 221, private equity 222, and 
collectibles 223 such as art Data regarding non-market traded assets 220, including valuation 
data, may be entered by the client (subscriber or participating owner) or the client's 
authorized agent through a data entry interface that is part of the GUI according to one 
embodiment of the present invention. Non-market traded asset 220 data may also be 
provided to the present invention provider whose staff may manually enter the data into the 
system according to one embodiment of the present invention. For example, the client or 
authorized agent may provide the data electronically, by telephone, or in printed form to the 
present invention provider. Liabilities 225 is the third aggregation category displayed in FIG. 
2. Liabilities 225 includes, among others 229, credit lines 226, mortgages 227, and loans 
228. These three categories are merely exemplary and are not intended to be exhaustive. 
These categories help organize how data aggregation occurs and can be used in varying 
degree in different. embodiments, of the present invention. The- actual organization of the ■ 
aggregated data occurs during the protocol mapping process which converts the retrieved 
client financial data into an appropriate format to be stored in the consolidation database 230. 

The consolidation database 230 can be one or more actual databases that contain the 
client financial data. The example embodiment described herein and shown in FIG. 2 refers 
to the consolidation database 230 as a single database. Alternate embodiments can 
implement the consolidation database as a distributed database or as multiple databases 
linked and accessed through the data aggregation network node 1 00. 

Sequence of Events for Establishing a New Subscriber 



processed in the future. According to another embodiment of the present invention, the 
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FIG. 5a is a flowchart depicting an example sequence of events that take place during 
the process of setting up a new subscriber account according to one embodiment of the 
present invention. A written agreement between the operator and the subscriber is reviewed 
500. The agreement is reviewed to determine die nature and the extent of services to be 
provided to the subscriber. The initial set-up of the subscriber information is then performed 
in the system according to one embodiment of the present invention 502. The set-up of the 
subscriber information may be perfonned by, for example, the operations staff of the operator 
or by authorized agents according to one embodiment of the present invention. 

FIG. 5b is a flowchart depicting the steps involved in the initial set-up of subscriber 
information according to one embodiment of the present invention. In step 550, according to 
one embodiment of the present invention a unique identifier for the subscriber is assigned by, 
for example, either the operator staff or automatically (e.g., the subscriber management 
system module of the present invention). In step 552, entry and validation of the subscriber 
identifying information such as subscriber name, address, contact information, and tax status 
is performed according to one embodiment of the present invention. For example, subscriber 
identifying information may include a subscriber name such as "the Jones family" or "Gill 
Bates HI." In another example, the subscriber address may include one or more of the 
following: legal address, tax domicile, residence, mailing address, and temporary address. 
The contact information mentioned may, for example, include the name, telephone numbers, 
fax numbers, and email addresses of one more contacts for the subscriber. An example of tax 
status that may be included in the subscriber identifying information is a taxpayer identifier. 
Under certain circumstances, the subscriber or referring financial service provider may want 
to keep some or all of the identifying information (i.e.,.subscriber, participating owner, agent, 
addresses, contact information, and tax status) confidential (hidden from the data 
consolidation network node). For example, the subscriber may only want his/her account 
manager at the referring financial service provider to know the information. In this case, all 
the identifying information to be kept confidential may be maintained at the referring 
financial service provider and only the locally generated identifiers, i.e., generated by the data 
consolidation network node, may be used according to one embodiment of the present 
invention. 

In step 554, the selection of a subscriber type from a list of supported subscriber types 
is performed according to one embodiment of the present invention. Alternative 
embodiments may allow custom designation and dynamic generation of subscriber types. For 
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example, subscriber types may include individual, family, partnership, trust, s-corporation, 
foundation, and public institution. The selection of a subscriber type may, according to one 
embodiment of the present invention, trigger ferther prompting for additional or particular 
data specific to that type of subscriber. 

In step 556, the financial service provider referring the subscriber to die operator 
(referring financial service provider) is identified according to one embodiment of the present 
invention. For example, a referring financial service provider may be identified by an 
industry standard identifier code or by financial service provider name. If die subscriber 
interacts directly with the operator or an agent of the operator without going through a 
financial service provider as an intermediary for the present invention services, the referring 
financial service provider identification may be omitted or the operator or agent may be used 
as the referring financial service provider according to different embodiments of the present 
invention. According to one embodiment of the present invention, the referring financial 
service provider information is used by the present invention to monitor the subscriber- 
operator relationship for compliance with the terms of the agreement and for payment 
purposes. 

In step 558, according to one embodiment of the present invention, the chart of 
accounts to be used by the subscriber is identified. For example, a subscriber may initially be 
assigned a default chart of accounts used by the present invention, wherein the chart of 
accounts is the default for all new subscribers, for all subscribers of the same subscriber type, 
for all subscribers ftom die same referring financial service provider, or a combination of the 
aforementioned. According to one embodiment of the present invention, a customized chart 
of accounts specially created to meet a subscriber's specifications may be used as the initial 
chart of accounts assigned to the subscriber if it has been created prior to the set-up of the 
subscriber identifying information. 

In step 560, according to one embodiment of the present invention, the asset 
classification scheme to be used by the subscriber is identified. For example, a subscriber 
may initially be assigned a default asset classification scheme used by the present invention, 
wherein die asset classification scheme is the default for all new subscribers, for all 
subscribers of the same subscriber type, for all subscribers from the same referring financial 
service provider, or a combination of the aforementioned. According to one embodiment of 
the present invention, a customized asset classification scheme specially created to meet, a 
subscriber's specifications may be used as the initial asset classification scheme assigned to 
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the subscriber if it has been created prior to the set-up of the subscriber identifying 
information. In one embodiment of the present invention, the asset classification scheme may 
be different than the client data aggregation categories (discussed in the data aggregation 
section of this specification) that may be provided by the financial service provider to assist 
in the aggregation of the client data. The above mentioned steps in FIG. 5b are not 
mandatory and their order may change according to various embodiments of the present 
invention. 

Returning now to FIG. 5a, in step 504 all of the participating owners under the 
subscriber agreement are identified. The entry of identifying information concerning 
individuals and legal entities that participate in subscriber wealth, i.e., termed "participating 
owners", may be performed by the operations staff of the present invention provider or by 
authorized agents according to one embodiment of the present invention. Participating 
owners are added by specifying the appropriate already existing subscriber (the subscriber 
can be chosen from a list of existing subscribers or directly entered) and then entering and 
validating the basic identifying information for the participating owners according to one 
embodiment of the present invention. Participating owner basic identifying information may, 
for example, include name, social security number or tax ID, grader, date of birth, address of 
residence, mailing addresses, telephone and fax numbers, email addresses, and country of 
citizenship. The exact nature of the basic identifying information may depend on the type of 
entity the participating owner is according to one embodiment of the present invention. For 
example, a participating owner may be an individual or a legal entity such as a trust, 
foundation, institution, s-coiporation, or partnership. If a subscriber's identity is kept 
confidential, as- previously discussed, the participating owner identity may also be kept 
confidential in the same manner by having the referring financial service provider maintain 
the participating owner identifying information and by having the present invention use only 
the locally generated identifiers (those generated by the present invention) as the participating 
owner basic identifying information. 

In step 506, the relationship structure between the participating owners is established. 
According to one embodiment of the present, the relationship structure is established by 
providing a basic definition of the relationships.between the participating owners for an 
existing subscriber. For example, these relationships may be familial, fiduciary, or otherwise 
defined amongst the participating owners.. . According to one embodiment of the present 
invention, the relationship information is provided to the operator by the client and entered 
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into the system by the operator staff. 

FIG. 5c is a block diagram illustrating the steps in defining the relationship structure 
between the participating owners according to one embodiment of the present invention. A 
relationship structure includes the individual relationships amongst the participating owners. 
In step 562, according to one embodiment of the present invention, the subscriber is 
identified. For example, the identification of the subscriber can be done through the selection 
of a existing subscribers from a list Instep 564, a source participating owner is selected 
according to one embodiment of the present invention. A source participating owner may 
already be defined in the system and is the participating owner for whom the relationship is 
specified. For example, using the entities shown in FIG. 5d, in order to define Bill as the 
parent of Samantha, Bill would be selected as the source participating owner. Just as a source 
of the relationship is chosen, a target participating owner is also selected 566 according to one 
embodiment of the present invention. For example, in order to define the relationship given 
in the example above, Bill would be defined as the source participating owner and Sa m a ntha 
as the target participating owner. Once both a source and target of the relationship is 
selected, the type of relationship may be defined 568 according to one embodiment of the 
present invention. A relationship type may, for example, include: familial, fiduciary, and 
legal. According to one embodiment of the present invention, a relationship subtype may also 
be selected 570 further defining file relationship. For example, a relationship subtype may 
include: spouse, parent, child, sibling, sponsor, and guardian. In an alternative embodiment 
of the present invention, no relationship subtype is used and instead die relationship type is 
more descriptive like the subtype previously mentioned; In the previously given example, 
Bill, the source participating owner, has a familial relationship of the parent relationship, 
subtype with target participating owner Samantha. Conversely, Samantha the source 
participating owner has a familial relationship of the child relationship subtype with target 
participating owner Bill. In addition to relationship type and subtype, other relationship 
characteristics may also be defined 572 according to one embodiment of the present 
invention. Other relationship characteristics may, for example, define if there is joint or 
individual reporting for husband and wife in a spouse relationship. Once the aforementioned 
information has been defined and selected for a relationship, the process is repeated for other 
relationships between the participating owners for a subscriber until the entire relationship 
structure is defined. The aforementioned steps in FIG. 5c are not mandatory and their order 
may change according to various embodiments of the present invention. 
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FIG. 5d is a block diagram illustrating a sample relationship structure for a subscriber. 
Bill 574 is the patriarch of the family and is married to Martha 576 both of which are the first 
generation in this femily (denoted by Gl for Bill denoting first generation and Gl-S for 
Martha indicating spouse of a femily member). Reporting for Bill and Martha is done jointly 
and therefore there is no distinction such as Gl A and GIB for each. In this example, Helen 
578 is Mary's 576 sister and shown by a dashed lined relationship for sibling. The OPO 
refers to other participating owner. Bill 574 and Mary 576 have two children Samantha 580 
and Bob 582 who are both second generation (G2) in this familial structure are reported on 
separately indicated by the G2A for Samantha 580 and the G2B for Bob 582. Bob 582 is 
married to Jessica 584 and joint reporting is done for them indicated by the G2B for both Bob 
582 and Jessica 584. Jessica's 584 status as a spouse marrying into the femily is denoted by 
the additional S designator in the G2B-S. Bob 582 and Jessica 584 have two children 
Theodore 586 and Judy 588 who are jointly reported on as indicated by the G3A designator 
indicating joint reporting for the third generation. FIG! 5d is merely an exemplary diagram to 
illustrate a relationship structure and does not necessarily indicate any type of reporting or 
code usage (e.g., Gl , Gl-S, G2A, etc.) by the present invention. 

In step 508 of FIG. 5a, the subscriber holding entities are established. Subscriber 
holding entities are the legal entities that participate in asset ownership. Holding entities both 
own assets are themselves owned by participating owners or by other holding entities. 
Holding entities are typically established to limit liability, to achieve specific private and 
femily ownership goals, take advantage of tax laws, comply with regulations for certain 
industries or geographical areas, or for a number of business reasons. The steps necessary in 
establishing a holding (or. legal) entity, begin, according to one-embodiment of the present 
invention, with identifying the subscriber for which the holding entity is to exist According 
to one embodiment of the present invention, the holding entity is unique within a subscriber 
but not necessarily across subscribers and, therefore, a unique holding entity (legal entity) ID 
is generated. According to one embodiment of the present invention, the basic identifying 
information for the holding entity is then entered and validated The basic identifying 
information may include such information as name, tax ID, addresses, phone numbers, fax 
numbers, email addresses, and contact information. Holding entity information is, according 
to one embodiment of the present invention, received from the client or authorized source and 
entered by the operator's staff. Next, according to one embodiment of the present invention, 
the holding entity type is specified. For example, a holding entity (also termed "legal entity") 
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may be a limited liability company (LLC), a partnership, a trust, an s-corporation, a 
foundation, or a public institution. Holding entities are also referred to as legal entities 
throughout this document — - 

Once the holding entities have been defined, according to one embodiment of the 
5 present invention, the subscriber ownership structure may be defined in step 510 of FIG. 5a. 
The subscriber ownership structure is the identification of which participating owners and 
legal entities have ownership stakes in the other legal entities, assets, and accounts and what 
their specific ownership stakes are. The subscriber ownership information may be entered by 
the client or authorized agent directly or may be sent electronically or by hard copy to the 

10 operator, whose staff may then enter the information into the system. According to one 
embodiment of the present invention, the subscriber for whom the subscriber ownership 
structure may be entered is identified. Next, according to one embodiment of the present 
invention, the source which is the participating owner or legal entity that has an ownership 
stake in another legal entity, asset, or account is identified. Also, according to one 

15 embodiment of the present invention, the target which is the legal entity, asset or account over 
which ownership exists is identified. The percentage ownership that the source has in the 
target may be identified. For example, participating owner A (the source) may have 20% 
ownership of s-corporation X (the target). This process may be repeated for each ownership 
interest for the subscriber. These individual ownership interests makeup the subscriber 

20 ownership structure. 

In step 512 of FIG. 5a, according to one embodiment of the present invention, the 
scope of access provided may be defined. Authorized agents (and certain accessing 
participating owners), acting, on behalf of participating owners and holding entities of the 
subscriber are granted viewing rights to specific holding entities, assets, and accounts 

25 associated with a subscriber. The scope of access may be, for example, entered into the 
system by the operator's staff, by the subscriber, or authorized agents. According to one 
embodimentof the present invention, the scope of access provided is uniquely specified for 
each entity given access permission to the data even if the access permission granted is 
identical. For example, according to one embodiment of the present invention, the subscriber 

30 for which the scope of access applies may be identified. Then, a unique identifier and., 
descriptive name for the scope of access definition may be generated. Alternative 
embodiments of the present invention do not require either a unique identifier, a descriptive 
name, or both. The authorized agent or participating owner for which the scope of access is 
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to be defined is then identified. Next, according to one embodiment of the present invention, 
the selection of a holding entities, assets, and accounts for which access is to be granted may 
be made. In one embodiment of the present invention, groupings of holding entities, assets, 
and accounts may be defined and these grouping may be used in defining scope of access. An 
alternative embodiment of the present invention instead allows the specification of specific 
holding entities, accounts, and assets from those that have already been defined for the 
subscriber. In another embodiment of the present invention a combination of groupings and 
specific holding entities, accounts, and assets may be selected when defining scope of access. 
This process may be repeated for each scope of access to be provided. 

In step 514 of FIG. 5a, a chart of accounts is set-up. A chart of accounts are the 
bookkeeping and accounting accounts to be maintained by the accounting module according 
to one embodiment of the present invention. It is possible according to one embodiment of 
the present invention to implement a standardized account structure used by all subscribers. 
A more advantageous and flexible embodiment of the present invention allows subscribers to 
customize the chart of accounts they use in order to meet any particular reporting needs or 
desires they may have. 

In step 516 of FIG. 5a, actual investment information is entered. All appropriate 
identifying information regarding the asset or liability may be entered so that it can 
appropriately be tracked by the system. The information is provided by the subscriber, the 
participating owners, authorized agents, and financial service providers either by electronic 
entry through a data entry interface, through a data feed, or by electronic or hard copy 
transmission to the operator whose staff enters the information. Non-market traded assets, 
such as art- and real estate, may have their valuation information provided directly by an 
authorized agent of the subscriber. This is an advantageous method of receiving valuation 
information for non-market traded assets even where these assets receive periodic valuations 
or appraisals made by external authorized sources because these assets are difficult to value 
and frequently do not sell for appraised value. Non-market traded assets are added, according 
to one embodiment of the present invention, by identifying the subscriber, generating a 
unique asset ID (e.g., VTN for antique automobile or airplane, property address or plot 
designator for real estate, and descriptor for a piece of fine art), and providing and validating 
the asset identifying information. For example, asset identifying information may include 
asset name, description, and asset classification category, which may be a default scheme or a 
subscriber-defined customized scheme. Additional elements of asset identifying information 
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may also be included and may be specific to the asset type. 

In addition to non-market traded assets, subscriber account information may also be 
added according to one embodiment of the present invention. Accounts are groupings of 
assets that mimic the participating owner or holding entity accounts at the financial service 
providers. Information about assets can be consolidated by account, such as balances, and 
positions in assets or asset categories. Accounts may have a unique identifier in the present 
invention system that is different than the account number used by the financial service 
provider. If so, a mapping between the two numbers is available. Market traded assets may 
also be added to the investment information according to one embodiment of the present 
invention. Market traded assets are first be defined in the security universe, a master library 
of security information containing general information about the security, before being added 
to investments according to one embodiment of the present invention The investment 
information may then only consist of the additional information necessary to detail the 
holding for the participating owner or holding entity. The process of adding a market traded 
security asset to the investment information begins, according to one embodiment of the 
present invention, with the first step of identifying the subscriber for whom the investment 
information is to be added. The account for which the asset is to be added may also be 
specified as well as the asset type. A valid industry standard asset identifier, such as dCUSIP 
or other identifier, may also be specified where available for the security. Additional tracking 
and accounting information may also be included. For example, cost basis information 
determined by averaging or by tax lot may also be included. The terms for future contracts, 
forward contracts, and options contracts may also be entered and validated. 

In step 518 of FIG. 5a, authorized agents related to the participating owners, holding 
entities, or the individual assets of the participating owners are identified. For each 
authorized agent, a scope of access definition may also be provided as previously discussed. 
In step 520, the initial holdings information are entered. Initial holdings information, for 
example, includes the amount of the holding, the tax basis for the holding, and other 
descriptive information regarding the holding. In step 522, according to one embodiment of 
the present invention, initial reports for all assets of each participating owner are prepared to 
ensure that initial data was correctly entered into the system. For example, balance sheets, 
holdings reports, and allocation reports may be prepared and reviewed. 

Steps 524-528 are repeated as information is updated for the subscriber. In step 524, 
the entry of valuation information for all assets as of a particular valuation date may be made. 
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The valuation information for market traded assets such as stocks may be obtained from 
market data providers such as commercial quote services while the valuation information for 
all non-market traded assets such as art, collectibles, & real estate may be provided by the 
client even if third party appraisals are available because the sale or purchase value of these 
types of assets often do not match the appraised value. Hie preparation of reports 526 is the 
process of establishing a new subscriber according to one embodiment of the present 
invention. The scope of the reporting, such as which participating owner may be included in 
the reports and which of their assets may be included, may be defined before the reports are 
prepared. For example, reports are prepared for the entire subscriber as well as for each 
participating owner individually. When participating owners are married, separate reports 
may be prepared for their jointly owned assets, their individually owned assets, and the 
combined assets of both spouses. According to one embodiment of the present invention, 
transaction data is then entered 528. For example, transactions for both market traded assets 
and non-market traded assets may be entered in the system (the consolidation database) and 
the appropriate updating of the general ledger (chart of accounts) data may be made. 
Valuation information may be updated for the subscriber ownership structure 524 which in 
turn may result in the preparation of updated reports 526. Transaction information may 
continue to be entered until the valuation information is again updated The aforementioned 
steps in FIG. 5a are not mandatory and their order may change according to various 
embodiments of the present invention. 

Periodic Processing of Subscriber Information 

According to one embodiment of the present invention, receiving transactions for 
subscriber accounts is a step in the periodic processing performed by the present invention 
whereby the financial service providers provide information to the system by electronic 
transmission of transactions affecting subscriber accounts. For example, transactions may 
include trade transactions for market traded securities, cash transfers, and cancellations or 
changes to trade terms. Transaction related information for market traded securities is 
received simultaneously with the actual trade transaction to provide current reporting of 
holdings for this type of security according to one embodiment of the present invention. For 
example, this electronically transmitted transaction related information may contain all details 
of the transaction including the dollar amount involved, identity of the security involved, 
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amount of the holding involved, date of the transaction, etc. The tasks involved in this step 
include receiving a file and checking that file for integrity according to one embodiment of 
' the present invention. For example, all files may have control measures to assist in the 
determination of whether a file transmission is complete. These control measures may for 
example include begin-file and end-file markers, record counters, etc. Then, according to one 
embodiment of the present invention, the receipt of the file is acknowledged and, if the file 
does not pass the integrity check, a request is made for the retransmission of the file. Next, 
the received data is reformatted, exceptions are determined, and the data is mapped to the 
appropriate rows/records and attributes/fields in the databases) of the present invention 
according to one embodiment of the present invention. Exceptions may for example result 
from a corrupt row/record structure in the received file, an attribute/field format in the 
received data not complying with the data rules specified, or the attribute/field value not 
falling within a specified domain or range. The sending financial service provider's account 
numbers are then mapped to the account numbers used by the present invention. Once the 
account numbers have been mapped, the transformed, mapped, and checked data may then be 
imported into and integrated with the data in the present invention databases according to one 
embodiment of the present invention. Also, the record of scheduled dam transmissions from 
the financial service provider for the account(s) may be updated. 

Subscriber transactions may also be recorded by the accounting module to facilitate 
the record keeping for the client According to one embodiment of the present invention 
client data transmitted by the financial service providers is handled by the data acquisition 
module (not shown in FIG. 2) which may send the information to the accounting module 245 
as well as Jo the consolidation databases). For example, data received for a transaction 
regarding a market traded security is not only stored in the present invention database(s) by 
the data acquisition module but is also sent to the accounting system so that this accounting 
information also remains current The process of transmitting subscriber account information 
from the data acquisition module to the accounting module 245 can occur when the new 
information is received and processed or may occur on a daily basis according to different 
embodiments of the present invention. The accounting module, according to one 
embodiment of the present invention, checks, with the asset/liability table discussed below 
(security universes) to determine if an asset has already been defined in the security universes. 
For example, the security universes are checked for each transaction forwarded to the 
accounting module by the data acquisition module. According to one embodiment of the 
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present invention, if the security is not already defined, the transaction is placed in an 
exceptions queue, where further processing is delayed until a message is received from the 
security information management module (not shown in FIG. 2) that the necessary 
modifications have been made to the security universes. 

Data Organization and the Consolidation Database 

The data consolidation component is responsible, according to one embodiment of the 
present invention, for using the specifications stored in the subscriber profiles to build 
financial consolidation structures, populate these consolidation structures, and facilitate the 
review of these populated consolidation structures. Consolidation structures link sets of 
investment owners, such as participating owners and holding entities, with sets of owned 
entities, such as accounts, assets/liabilities, asset/liability types, and holding entities. These 
consolidation structures are populated with detailed financial data (i.e., holdings, positions, 
pricing, valuations, transactions, and assessments) that is used to generate customized reports 
that meet the viewing, drill-down, and roll-up of subscriber participating owners, subscriber 
holding entities, and subscriber authorized agents. The populated consolidation structures are 
made available for review, both by automated means and by human review, in order to ensure 
die completeness, consistency, and interconnectedness of the data. 

According to one embodiment of the present invention, the primary and largest unit of 
data consolidation and reporting is the subscriber with no data consolidation taking place 
across subscriber boundaries. A subscriber may represent an individual, a legal entity (i.e., a 
partnership, trust, S-corporation, foundation, or public institution), or a consolidation of one 
or more of each. For example, a subscriber can represent a family consolidating the 
information on the individual family members versus another example where a subscriber 
represents only an individual. A subscriber is a unique unit of data consolidation established 
by either an individual who enters into a contract with the commercial entity operating the 
present invention or is established by a client of a referring financial service provider that, as 
part of their client services, offers access to the commercial entity operating the present 
invention. 

FIG. 3a illustrates a subscriber table 300 in the consolidation database according to 
one embodiment of the present invention. The subscriber ID field 301 contains a unique 
identifier serving as the table key. The subscriber name field 302 contains the subscriber 
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name used by the reporting module. The referring financial service provider field 303 
contains a unique identifier for the institution referring the client to the commercial entity 
operating the present invention and is only used where a referring financial service provider 
exists as opposed to the situation where an individual directly contracts with the commercial 
entity operating the present invention. The referring financial service provider name field 304 
contains the institution name, where applicable, that is used by the reporting module. The 
subscriber table 300 may contain additional or alternate information as may be desired by or 
necessary to various embodiments of the present invention. As stated previously, subscriber 
information may be obtained from the financial service providers and authorized agents 
providing services for the subscriber and/or associated participating owners. According to 
one embodiment of the present invention, subscriber information is obtained through data 
feeds established through data acquisition agreements between the operator and the data 
sources. 

According to one embodiment of the present invention, the data consolidated for a 
subscriber is organized into one or more entities, a secondary and lower level of data 
consolidation. An entity can represent a participating owner (an individual), a legal entity 
(i.e., a holding entity), or an account For example, given a subscriber representing a family, 
one entity may be a wife while another entity may be an investment management account 
partially owned by the wife. In the example discussed, the wife would be a parent entity and 
the investment account a child entity. An entity is also a unique data consolidation unit like a 
subscriber. 

FIG. 3b illustrates an entity table 3 10 in the consolidation database according to one 
embodiment of the present invention. The subscriber ID field 311 contains the unique 
subscriber ID for the subscriber under whom this entity fells. The entity ID field 312 contains 
a unique entity identifier and the entity name field 313 contains the name of the entity used by 
the reporting module. The entity type field 3 14 identifies the type of entity being described. 
For example, the entity type field 3 14 can indicate that the entity is a portfolio of accounts. 
The entity currency field 315 indicates the base currency used by this entity. The entity table 
310 may contain additional or alternate information as may be desired by or necessary to 
various embodiments of the present invention. 

Relationships exist between the entities and are appropriately defined. In the example 
embodiment, relationships are used to define ownership stakes but can, in other embodiments 
define a broader range of relationships. According to the above example, a relationship exists 



26 



WO 02/19229 




SOI/27283 



between the wife entity and the investment account entity. In this relationship, the wife is the 
parent entity having the ownership stake in the investment account, which is the child entity 
in this relationship. This example is more clearly shown in FIGS. 3c and 4b. FIG. 3c 
illustrates an entity relationship table 320 in the consolidation database according to one 
embodiment of the present invention. The relationship ID field 321 contains the unique 
relationship identifier for a given relationship. The parent entity ID field 322 and child entity 
ID field 323 contain unique entity identifiers for the parent and child entity respectively. The 
entity ownership field 324 contains a percentage value that indicates the percentage of the 
child entity owned by the parent entity. The role field 325 contains a classification value for 
die role of the relationship. In the above example, the wife participating owner is a parent 
entity and the investment account is a child entity, the percentage ownership that the wife 
exercises over the investment account is the entity ownership value. The entity relationship 
table 320 may contain additional or alternate information as may be desired by or necessary to 
various embodiments of the present invention. 

FIG. 4b illustrates a subscriber as a whole with all its subordinate entities and entity 
relationships according to one embodiment of the present invention. The subscriber is a 
founder 41 1 of a partnership 418 and die subscriber aggregates family data for the founder's 
family 412-414. Some of the entities for the subscriber represent individual participating 
owners 41 1-414. The founder 41 1 , bis wife 412, bis first child 413 and his second child 414 
are the four participating owners shown in FIG. 4b. These four participating owners 41 1-414 
have a parent relationship with a family trust entity 415. The relationships are shown by the 
lines connecting each participating owner 41 1-414 with the family trust entity 415. Each line 
also shows the percentage (the entity ownership value) of the family trust child entity 415 that 
each of the individual parent entity is entitled. For example, the founder 41 1 is entided to 
52% of the family trust 415 while the wife 412 and two children 413-414 are each entided to 
16% of the family trust The family trust 415 itself is a parent entity having the following 
ownership stakes in these child entities: 100% of an asset management account 416; 100% of 
a custodial account 417; and 75% of a partnership 418. The partnership entity 418 is also a 
parent entity with the following ownership stakes in these child entities : 25% of asset 
management account 2; 50% of custodial account 2 419; and 75% of the brokerage account 
421 . As stated earlier, all the entities in FIG. 4b belong to the same subscriber. The 
subscriber, entity, and relationship information- illustrated in FIG. 4b are stored in the 
consolidation database 230 in the previously described subscriber, entity, and entity 
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relationship tables respectively according to one embodiment of the present invention. 

Entities can be further defined according to the entity type 3 14. For example, 
Accounts and legal entities are two types of entities. FIG. 3d illustrates an account table 330 
in the consolidation database according to one embodiment of the present invention. The 
account ID field 33 1 contains the unique account identifier for a client account at a financial 
service provider 200 or financial service provider network node 190. The entity ID field 332 
contains the unique entity identifier that links the account information with the entity and 
relationship information in the entity 310 and the entity relationship 320 tables. Several 
additional fields can exist to further define the account Of particular interest according to 
one embodiment of the present invention is the source system information. The source 
system ID field 333 contains the unique identifier for the financial service provider 
processing the account The source system account ID field 334 contains the account 
identifier used by the source system (the financial service provider) to identify the client 
account The information contained in both these source system fields 333-334 are used by 
the present invention to obtain and update the client's financial information. For example, 
this information can be vised to match rows in the table with retrieved client financial 
information in order for the appropriate data to be updated and to prevent data redundancy 
(i.e., storing the same information in unnecessary additional rows of the account or entity 
tables). Hie account currency field 335 contains a value identifying the base currency used 
for the account This information is used for reporting and accounting purposes. The account 
table 330 may contain additional or alternate information as may be desired by or necessary to 
various embodiments of the present invention. 

Legal entities (i.e., "holding entities"), like accounts, are also a subset of entities. 
FIG. 3e illustrates an legal entity table 340 in the consolidation database according to one 
embodiment of the present invention. Each legal entity may be identified by a unique legal 
entity identifier 341 . The legal entity table 340 contains information about the legal entity 
and may be linked to the entity table 310 and entity relationship table 320 by an entity ID 
field 342, just like the account table 330 is. The legal entity name 343 and the type of legal 
entity 344 may also be included in this table. The legal entity type may, according to one 
embodiment of the present invention, be based on a legal entity classification scheme used by 
the present invention. This table may also contain a legal entity currency field 345 containing 
a value identifying the preferred currency for the legal entity. The legal entity currency field 
may be used to convert financial values into this currency value for reporting purposes. 
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Additional address and residency information for the legal entity may also be included in this 
table according to one embodiment of the present invention. The legal entity table 340 may 
contam additional or alternate information as may be desired by or necessary to various 
embodiments of the present invention. 

5 In the example embodiment of the present invention, entity changes, such as the 

addition or deletion of assets or changes in ownership, that modify the original consolidation 
information are recorded by date and tracked according to one embodiment of the present 
invention. This allows a historical record of modifications to the original consolidated client 
financial information to be kept The reporting module can provide the client with an 

1 0 accurate record of such changes. Entity changes can also result in entity annotations which are 
comments that are included by the reporting module with the information presented to the 
client Entity changes and annotations are maintained in one or more tables of the 
consolidation database. The entity changes can be made, according to one embodiment of the 
present invention, by the operator staff after they have received information from the client or 

15 authorized source regarding a change in the entity. In an alternative embodiment, entity 

changes may be sent electronically by the client or authorized source to the operator where 
they are either electronically or manually processed. 

Subscriber and entity information establishes the ownership relationships for the client 
financial information. The actual asset and liability information is stored in one or more 

20 additional tables and linked to the entities. These tables are discussed below following a 
general discussion of assets and liabilities. An asset is any item that may be owned or 
possessed as a right by an individual or legal entity that has an economic, commercial, or 
exchangeable value. For example, an asset may be stock in a corporation, real estate, a work 
of art, etc. A fiability is any item that may owed by an individual or legal entity. For 

25 example, a loan of any type is a liability . According to one embodiment of die present 

invention, assets are anything that can be owned versus items that are actually owned and 
liabilities are the tilings owed rather than the actual debt For example, a share of XYZ 
Corporation is an asset whether or not the client owns it and a mortgage is a liability rather 
the $50,000 owed on the mortgage. The actual ownership of an asset or the debt of a liability 

30 is represented by a position in the asset or liability. For example, as discussed below, a 

liability may be a mortgage defined in the asset/liability table while a position in the mortgage 
. is an actual amount of mortgage debt owed which is recorded in the position table. In another 
example, XYZ Corporation stock is an asset that may be defined in the asset/liability table 
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while the actual ownership of 1,000 shares of XYZ corporation stock would be a position in 
the asset and may be defined in the position table. 

FIG. 3f is a block diagram illustrating the asset/liability table according to one 
embodiment of the present invention. The asset/liability table 350 or tables contains the 
details about each asset and liability which may be needed in addition to the classification 
schemes discussed below according to one embodiment of the present invention. According 
to one embodiment of the present invention, unique identifiers 351 are generated by the 
present invention to identify each asset and liability. In addition to tins unique ID 35 1 , 
asset/liability names 353, such as "XYZ Corporation common stock", may also be included in 
the consolidation database. One embodiment of the present invention includes a source 
system identifier 352 to identify the source financial service provider where the asset/liability 
originated. This source system ID 352 coupled with an attribute for asset/liability code 
containing the unique asset/liability code used by the source system to identify the 
asset/liability may be used to linked the asset/liability information in the present invention 
with the source financial service provider according to one embodiment of the present 
invention. Other information about the asset/liability may also be defined in the present from 
the data provided during the data acquisition process. For example, maturity date 354 is the 
date that an asset/liability is repaid or a forward exchange contract is settled. Maturity date 
354 may be empty for assets/liabilities that do not have maturity dates such as equities. 
Interest rate 355 is another example of a descriptive field that may contain the annual interest 
rate applied to the particular asset/liability. Again, interest rate 355 may be empty for 
assets/liabilities that do not have interest rates such as equities. Another example of a 
descriptive field is price factor 356 that may contain the multiplier used to turn a bond 
percentage price into a decimal value. Price factor 356 may also be empty for 
assets/liabilities that are priced on a unit basis. In addition to a unique asset/liability identifier 
351 used by one embodiment of the present invention, assets may also be identified using 
industry standard identifiers when available such as the CUSIP 358 for traded assets in the 
United States and Canada, ticker symbol 357, Sedol, and Cedel (the last two are both 
international asset identifiers). The asset/liability tables may also take into account currency 
differences by tracking the asset/liability currency code 359 (the currency code of the 
currency in which the asset/liability is denominated), the asset/liability pricing currency (die 
currency paid for the asset or received for the liability), the income/expense currency 360 (the 
currency in which dividends and income are received or interest and payments are made). 
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The income/expense currency 360 may further be divided to differentiate dividends and 
interest currency from income and repayment currency though this may not be necessary. 
The asset/liability table 350 may contain additional or alternate information as may be desired 
by or necessary to various embodiments of the present invention. 

According to one embodiment of the present invention, assets and liabilities are 
classified according to a classification scheme. Asset and liability classification may be 
received from the financial service providers during the data acquisition stage according to 
one embodiment of the present invention. The financial service providers may use unique or 
customized classification schemes and therefore do not provide sta nd a r d iz a t ion across the 
data acquired for the subscriber. For this reason, one embodiment of the present invention 
provides a present invention generated universal classification scheme under which the 
asset/liability data received from the financial service providers is placed. For this 
embodiment, the data acquisition agreement between the operator and the financial service 
provider may provide a translation table between the classification scheme used by the 
financial service provider and the operator. As stated earlier, as part of the data transmitted to 
the operator, the financial service provider may provide the universal categories used by the 
present invention. If these universal categories are not provided by the financial service 
provider, the operator may use the translation table defined during the data acquisition 
agreement stage to find the appropriate category or categories for the asset/liability based on 
the classification used by the financial service provider. Another embodiment of the present 
invention has the operator's staff review the asset/liability information received and assign 
the appropriate universal classification or classifications. Another embodiment of the present 
invention, allows the universal categories to be defined by the subscriber for the subscriber 
data. Like the previous embodiment discussed, the data acquisition agreement may provide a 
translation table between the financial service provider utilized classification scheme and the 
subscriber-defined universal (across all financial institutions) classification scheme. Yet 
another embodiment of the present invention allows the classification scheme of one financial 
service provider to be used as the universal classification scheme for all subscribers or for a 
particular subscriber. For example, according to the embodiments discussed, three possible 
classification schemes are: 1) asset/liability type classification scheme, 2) industry 
classification scheme, and 3) accounting category classification scheme. The asset/liability 
type classification scheme uses asset/liability categories defined for the present invention. 
For example, the asset/liability categories for assets may include securities, mutual funds, 
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cash, and options. In a further example, asset/liability categories for liabilities may include 
mortgages, personal loans, and credit cards. In addition to an asset/liability category, assets 
may also be categorized by an industry classification scheme using industry category codes. 
For example, industry categories may include biotechnology, communications, energy, 
consumer durables, and financial services. The classification of assets by industry is usually a 
customized process by the financial service providers providing the client services. Some 
financial service providers may use a standard value in their industry classification such as a 
SIC while others may use their own industry codes and categories. Assets and liabilities may 
also be categorized according to accounting category classification scheme using accounting 
categories. For example, liabilities may be categorized as open such as a credit card or 
overdraft protection on a checking account In another example, liabilities may also be 
categorized current and noncurrent as per standard accounting practices. In one embodiment 
of the present invention, the classification scheme used by the referring financial service 
providers may also be maintained and may be linked to any additional classification scheme 
used by the present invention so that the original classification scheme is not lost and may be 
used by the reporting module, the other core services, and the value added services. 

As previously stated, actual asset ownership and liability debt amount information is 
maintained for the client in the position data not in the asset and liability data according to 
one embodiment of the present invention. Each position is linked to an account (an entity), 
an asset or liability, and a source system such as a referring financial provider that maintains 
the client's position. Information maintained for each position is stored in one or more tables 
of the consolidation database with the tables containing all the relevant information on the 
asset or, liability position. For example, a position for stock in XYZ Corporation (an asset) 
may include information on purchase data, cost basis, position currency code, market value 
data, and unrealized gain/loss information. Position data may contain all the information 
deemed necessary for thorough asset/liability tracking and reporting. Information about 
positions is received during the data acquisition process and position data may be part of the 
data acquisition agreement between a financial service provider and the operator. 

FIG. 3g is a block diagram illustrating the position table according to one embodiment 
of the present invention. The position table 365 may contain a source system code 366 for 
the financial service provider where the position information originated. The source system 
code 366 may be used to link the data between the position table with the financial service - 
provider during the data consolidation process where the transformed data is written into the 
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consolidation database. Each position may be assigned a unique position identifier 367 in 
order to identify the position according to one embodiment of the present invention. The 
position ID 367 may serve as the key for the position table in the consolidation database. 
Account ID 368 is the present invention generated account identifier and may be used to link 
the position with an account An account may be composed of one or more positions in 
various assets and liabilities and therefore it is advantageous to link the position with its 
associated account The position table 365 may also contain a source system account ID 369 
that zan be used in conjunction with the source system code 366 to link the position data with 
a position for an account rnaintain ed by the financial service provider. As stated before, this 
information assists in the data consolidation process where the data from the financial service 
provider is mapped to data stored in the present invention. Each position, according to one 
embodiment of the present invention is a stake in an asset or liability and so an asset/liability 
ID 370 may also be included in the position table 365 for identification purposes. A source 
system asset/liability ID 371 may also be included to help map the present invention 
asset/liability ID to the asset/liability ID used by the source financial service provider. Other 
descriptive fields may be included about the position defining any necessary details. For 
example, units 372 is a field containing the number of units involved in this position. 
Another example is the price in nominal currency and position currency code 373 fields 
which may include the current price of the position in the currency of the position and a code 
identifying the currency of the position price. This information may be used with additional 
fields such as the price in base currency and base currency code 374 which may include the 
current price of the position in the base currency of the account and the code identifying the 
currency of the account The price effective date 375-field may contain the date the current 
price was determined. Other or alternate descriptive fields concerning the position may be 
included in the position table or tables as deemed necessary in other embodiments of the 
present invention. 

In addition to individual positions, information about total by position may be stored 
in one or more tables of the consolidation database according to one embodiment of the 
present invention. The total data can be for a particular asset/liability or for a classification 
scheme. For example, total by position data can be the total by asset/liability category on a 
given date such as the total in equities on August 1, 2000. In another example, total by 
position data can be the total by industry classification scheme on a given date such as the 
total in energy sector assets (stock) on August 1 , 2000. Totals by position are based on 
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aggregating information provided by the financial service providers and therefore, according 
to one embodiment of the present invention, this information is calculated by the present 
•i invention using the present invention's classification and is not information that is provided 
during the data acquisition process. Many different totals by position may be calculated for 
an entity such as a participating owner, legal entity or an account For example, a total may 
be calculated for all market traded assets in the biotechnology industry. This total would be 
calculated by adding up the current position valuations for all the assets that have been 
classified as being biotechnology market traded assets according to the asset/liability 
classification scheme previously discussed. 

Tax information may be kept in one or more separate tables of the consolidation 
database, may be incorporated in the fields of other tables in the consolidation database, or 
may be kept in a combination of both according to one embodiment of the present invention. 
For example, tax information may be tracked by tax lot, a subset of a position (sub-position), 
with a fixed asset purchase date and cost basis from which to calculate tax liability. Tax 
information may include purchase dates in order to calculate long-term versus short-term 
gains and losses as well as cost basis for the tax lot, where a tax lot is a purchase that is 
grouped together for tax purposes. For example, if participating owner buys 1 00 shares of 
XYZ corporation for $61.25 on Tuesday and another 100 shares at $61.25 on Thursday, both 
purchases may be separate tax lots because of the date which is important capital gains 
calculations which affect the amount of tax paid. Tax information comes from the transaction 
information provided by the financial service providers according to the data acquisition 
agreement and may be maintained separately from the other transaction data even though 
some redundancy may exist 

In addition to accounts and positions, transactions may also be accounted for in the 
consolidation database according to one embodiment of the present invention. A transaction 
records the execution of a business event such as a trade, corporate action, or other activity 
effecting the assets or liabilities of the client For example, buy and sell transactions for 
assets or borrow and repay transactions for liabilities may all be recorded and stored in one or 
more tables of the consolidation database. Buy transactions are the purchase or receipt of an 
asset while a sell transaction is the exchange or trade of an asset Borrow transactions are the 
incurring of a liability (taking on debt) while a repay transaction is a partial or full repayment 
of the debt for the liability . In another example, purely accounting transactions that impact a 
client account or position may also be recorded in the consolidation database. Accounting 
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transactions record the financial effects of a business transaction. Transactions show how an 
account or position has changed and for what reason. Transactions may be used not only to 
calculate changes in the clients financial data but also may be used by the reporting module. 
In one embodiment of the present invention, the type of transaction is also recorded in the 
5 consolidation database. 

FIG. 3h is a block diagram illustrating the transactions table 380 according to one 
embodiment of the present invention. The source system code 381 identifies the financial 
sendee provider transmitting the transaction information to the present invention. The 
asset/liability code 382 identifies the asset or liability for which the transaction was 

10 performed. The entity ID 383 identifies the owner tracking the asset/liability in question. 
These three fields are used to link the transaction to a source financial service provider, an 
asset/liability already defined in the consolidation database, and an entity exercising some 
ownership over the asset/liability positions involved in the transaction. Additionally, 
according to one embodiment of the present invention, a unique transaction ID 384 may also 

15 be used to uniquely identify each transaction. A transaction type 385 may help identify the 
type of transaction that has occurred. For example, a transaction type may indicate a 
purchase, a sale, cash transferred in, cash transferred out, shares transferred in, share 
transferred out, deposits, and withdrawals. According to various embodiments of the present 
invention, various dates may be stored for the transaction. For example, the transaction date 

20 386 may record when the transaction was conducted. Other dates may include the effective 
date of the transaction and the settlement date for the transaction. The number of units of the 
asset/liability involved in the transaction 387 may also be stored in the transaction table. The 
status of the transaction 388 is also data that may be relevant and stored in the transaction 
table as well. For example, a transaction status may be executed, : pending, or setded. Several 

25 price and currency figures may also be stored in the transaction table. Unit price (the price 
per unit on die transaction date), the transaction currency 389 (the currency for the 
transaction) are two examples of price and currency information that may be relevant Other 
fields in the transaction table may include accrued interest nominal currency (accrued interest 
of die asset/liability expressed in the currency of the asset/liability), accrued interest base 

30 currency (accrued interest of the asset/liability expressed in the base currency of the account), 
transaction commission in transaction currency, transaction commission in base currency, 
settlement amount in settlement currency, setdement amount in base currency among others. 
The transactions table 380 may contain additional or alternate information as may be desired 
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by or necessary to various embodiments of the present invention. 

According to one embodiment of the present invention, data concerning totals by 
transaction type may also be stored in one or more tables of the consolidation database. 
Totals may be calculated and stored by transaction type and for any given asset or liability 
attribute resulting in many possible combinations for the total-of calculation. For example, 
all sell transactions for XYZ Corporation shares during the past month could become one 
total by transaction type tracked and stored by the present invention. In another example, all 
purchase and sell transactions for XYZ Corporation bonds during the past six months could 
become another total by transaction type tracked and stored by the present invention. 
Because of the flexibility provided in determining the scope of the total by transaction to be 
tracked and stored by the present invention, the total by transactions tables may require 
sufficient fields to adequately specify what is being tracked as well as sufficient fields to 
adequately describe the calculation of the total by transaction type. 

In one embodiment of the present invention, one or more additional tables may be 
included in the consolidation database to adequately store accounting information needed by 
an accounting system for the client financial data. For example, accounting information used 
to generate the general ledger accounts (the books) for the client can be stored in these tables. 
In one embodiment of the present invention, performance benchmarks can also be calculated 
and stored in the consolidation database in order to help the client examine the performance 
of his/her financial investments. The present invention may include other information 
necessary to provide the necessary and desired services for the clients. 

Core Services 

The present invention provides several core services for the client as part of the data 
analysis stage of processing according to one embodiment of the present invention. FIG. 2 
illustrates example core services 241 in the data analysis portion 240 of the business method. 
Core services may include data reconciliation (not shown in FIG. 2), the reporting module 
242, compliance procedures 243, relationship management 244, and an accounting module 
245 each of which are discussed below. 

Data Reconciliation 

According to one embodiment of the present invention, two types of data 
reconciliation may occur, for example. During the process of retrieving and entering the 
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client financial data into the consolidation database 230, the data and the calculations made 
by the financial service providers are rechecked in order to reconcile the information coming 
Scorn several sources according to one embodiment of the present invention. Reconciliation 
can be performed to any degree from no reconciliation at all on one end of the spectrum to 
reconciling die data to the greatest extent possible based on the data available on the other 
end of the spectrum. The example embodiment performs thorough reconciliation of the data. 
Discrepancies are tracked and reported. The reporting of reconciliation discrepancies can be 
directed to either or both the client and the financial service providers from the data in 
conflict is received. As previously stated, according to one embodiment of the present 
information, information received from a financial service provider that does not reconcile is 
sent to an exceptions queue where the conflict is resolved before the data is added to the 
consolidation database. The data may be received from the financial service provider as part 
of the data acquisition agreement and the resolution of an exception may occur in a number of 
ways. For example, the operator's staff may resolve the exception by directly contacting the 
financial service provider. The exception may, according to another example, also be sent 
electronically to the financial service provider requesting that the data be rechecked and 
resent 

The second type of data reconciliation is the reconciliation of the data stored in the 
consolidation database 230 with the data maintained by the financial service providers 200. 
This second type of reconciliation allows the present invention to stay synchronized with the 
client's positions at the financial service providers so that the present invention does not 
misreport the client's financial situation. Recojiciliation of this nature may ideally be 
performed real-time but may also, be done as. a scheduled batch process. Real-time 
reconciliation can be performed if, for example, the financial service provider 200 is 
equipped to handle it; otherwise scheduled batch processing may be one alternative used* 
Scheduled batch processing may include an automatically executing file that initiates the 
reconciliation process. The automatic execution of the file is typically performed at a set time 
at which time the reconciliation process initiates. Reconciled data is stored in the 
consolidation database according to one embodiment of the present invention. This second 
type of reconciliation is handled through the data feeds established as part of the data 
acquisition process and data acquisition agreement previously discussed according to one 
embodiment of the present invention. If the financial service provider is not able to 
adequately transmit transactipns electronically, a delay in the updating may occur and thus 
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alternative expeditious means may be sought to maintain the synchronization of the present 
invention data with the financial service provider data. 

Reporting Module 

The reporting module 242 is the reporting subsystem of the present invention and 
allows the client to view the data in multiple configurations according to one embodiment of 
the present invention. Data can be presented to the client in a number of formats and 
presentations reflecting numerous possible combinations and aggregations. For example, a 
portfolio view of the information may present the client with financial data by portfolio while 
an asset type view may present the client with data by asset type such as equities. Other 
presentations of data can include an account view or an exception view of the client' s 
financial information. Report presentations can be in fixed formats either representing a 
custom format developed for the reporting module or mimicking a format used by a financial 
service provider feeding client financial data to the present invention. Report presentations 
may also be in a format that can be customized by a client either on a one time basis or to be 
saved for future use. Three example formats of the many in which report presentations can be 
made include computer screens holding data in various configurations such as Web pages, 
printouts mailed to the client, and formatted email messages sent to the client Report 
presentations can be provided to the client directly by the commercial entity operating the 
present invention or they can be reformatted to reflect the identity and/or presentation style of 
a licensed distributor linking the ciient to the commercial entity operating the present 
invention. The consolidation database 230 contains the additional fields and tables necessary 
to generate a diverse range of reporting on the client financial data and the data analysis 
performed by tte present invention. 

The reporting module uses the specification captured in the subscriber information to 
build or define the reporting structures or views of the consolidated information pertaining to 
sets of investment owners (i.e., participating owners and holding entities of subscribers) and 
sets of owned entities (i.e., accounts, assets, asset types, and holding entities). The reporting 
structures or views may then be populated with detailed consolidated information from the 
consolidated database and the results depository database. For example, the data used to 
populate the reporting structures may include holdings, positions, pricing information, 
valuations, transactions, etc. necessary to generate customized reports that meet the 
aggregation, analytical, drill-down (detailed viewed), and roll-up (summarized view) for the - 
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subscriber participating owners, holding entities, and authorized agents. Information may, 
according to one embodiment of the present invention, be included in a report where the 
scope of access for the report requestor permits the information to be viewed. Reports are 
generated according to pre-specified and ad hoc report formats using the populated reporting 
information. 

FIG. 6 is a block diagram illustrating how reporting views may be granted according 
to the defined scope of access according to one embodiment of the present invention. The 
information shown is for the Jones Family as the subscriber. Peter 601 and Lorraine 602 are 
spouses who are limited partners in the Jones Family Capital Management 608 with each 
spouse having a 49.95% stake. Matt 603, Susan 604, Ron 605, and Tina 606 are Peter 601 
and Lorraine's 602 children. Matt 603, Susan 604, and Tina 606 each have a stake in the 
Jones Family Corporation 607 which in turn is a general partner owning a 0.1% stake in the 
Jones Family Capital Management Ron 605 and Tina 606 also own 50% stakes in trust 2 
610 while Peter owns a 60% stake and Lorraine owns a 40% stake in trust 1 609. Both trust 1 
609 and trust 2 6 10 are shown without their underlying assets in this diagram. In addition to 
these holding entities, each of the participating owners (Peter, Lorraine, Matt, Susan, Ron, 
and Tina) have their own underlying assets 620-627. The Jones Family Capital Management 
608 is shown with its underlying assets: cash 611, market traded assets 612, non-market 
traded assets 613, and notes receivable 614. When a participating owner or authorized agent 
receives reports through the GUI interface or in hard copy format, the information is limited 
to the scope of access granted and is also based on the view according to one embodiment of 
the present invention. For example, if Lorraine views reports from her participating owner 
point of view, she may. see her underlying assets 621, the trust 1 as a whole 609 and the Jones 
Family Capital Management as a whole 608. From this view of Lorraine's assets, she can 
drill down the information to get additional details. For example, by double clicking on the 
Jones Family Capital Management aggregated information 608, Lorraine or her authorized 
agent may view the categories of underlying assets such as cash 611, market traded assets 
612, non-market traded asset 613, and notes receivable 614. This information may again be 
expanded for greater detail. The scope of access authorizations may limit Lorraine from 
seeing assets from Peter's point of view-Peter's underlying assets 620, Peter's stake in Trust 
i 609, and in Jones Family Capital Management. In another example of a view, if a 
participating owner who has been given the appropriate access to view the Jones Family 
Corporation 607 (such as Susan may have) can see the asset holdings from the Jones Family 
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Corporation 607 point of view. In this case it will be the 0.1% share in the Jones Family 
Capital Management 608. 

*' Views are the presentation of information from the perspective of a participating 
owner or a holding entity and involve the grouping of the underlying assets according to one 
embodiment of the present invention- According to one embodiment of the present invention, 
assets and liabilities are categorized according to a classification scheme as previously 
mentioned. This classification scheme is used to present information group by category for 
the particular view. The categories may be the same as the asset/liability classification 
scheme or may be a separate categorization scheme used for reporting. For example, some 
assets for the Jones Family Capital Management 608 may be grouped together as market 
traded assets. These assets may then be listed in one category that when expanded (drilled 
down) show the underlying market traded assets. For example, market traded assets may be a 
category with $44,000,000 in assets. When the market traded assets category is expanded, the 
$44 million is broken down into the following ten subcategories: 

Kemper 8,000,000 

Putnam 10,000,000 

Gameo 5,000,000 

McDonald & Company 4,000,000 

Baird & Company 3,000,000 

Old Kent Bank Stock 2,000,000 

One Ounce Eagle Gold Coins 1,500,000 

Templeton-EMS 2,500,000 

Templeton-FES 3,500,000 

Genmar Bonds 5,000,000 

It is possible to further expand these subcategories according to one embodiment of the 
present invention. The categories shown above are merely exemplary. The actual categories 
may derive from operator generated universal categories for all subscriber according to one 
embodiment of the present invention. Participating owner or subscriber designated categories 
may also be used according to another embodiment of the present invention. For example, a 
participating owner may customize the default system provided categories or may be asked to 
supply their own reporting category scheme. Again as stated before, the asset/liability 
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classification scheme may be used for the reporting categories according to one embodiment 
of the present invention. 

Compliance 

Compliance rules 243 are rules established by die client to govern the client's 
accounts. For example, a compliance rule may be that no more than 10% of the client's 
account is invested in high-technology stocks. Compliance rules 243 such as this are 
common at financial service providers but are limited to only the client's assets under 
management by that financial service provider. For example, if a client invests 40% of their 
assets with financial service provider A and 60% with B and implements a compliance rule 
with provider A that no more 10% of client's assets will be invested in high-technology 
stocks, the compliance rule may only impact the client assets under provider A's 
management According to one embodiment of the present invention, a compliance rule can 
be implemented by the client at the data aggregation network node 100 governing all the 
clients assets across multiple financial service providers. The present invention, according to 
this one embodiment, implements a, universal compliance rule that previously was not 
possible because compliance rules were implemented on an individual financial service 
provider (institutional) basis. 

The example embodiment of the present invention addresses the situation where a 
client violates a compliance rule. For example, if the client's assets exceed the compliance 
rule for having a maximum of 10% of the client's assets in high-technology stocks, a forced 
sale may be implemented, or the client may simply be informed of the situation and asked to 
act For example in this situation, the client is informed that they have violated their own 
compliance rules which they have created. Once the client is so informed, it remains up to 
the client whether to alter their compliance rules or to take action in order to bring their assets 
back in compliance. According to one embodiment of the present invention, the operator 
may be authorized to issue sell or purchase orders to the financial service providers in order 
to have a forced transaction in order to bring the client's assets back into compliance with the 
compliance rule. A forced transaction may be possible through a previously executed client 
authorization allowing the data aggregation network node to initiate transactions on the 
client's account(s) at the financial service provider. This may be done as part of the data 
acquisition agreement process. 

The example embodiment of the present invention also addresses a problem with 
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compliance rules, in particular, the lack of consistent definitions. For example, the definition 
of what constitutes a high-technology stock can and often does vary between financial service 
providers. Therefore, XYZ Corporation may be categorized a software company by financial 
service provider A, a high-capitalization stock company by financial service provider B, and 
an Internet company by financial service provider C. These distinctions make the 
implementation of a universal compliance rule very difficult because there may be different 
interpretations of whether the example 10% limit on high-technology stocks is violated In 
order to address this problem, one embodiment of the present invention implements at least 
one additional field in the asset and liability data with a universal category definition in 
addition to any source financial service provider given categorizations in the same data. The 
universal category definition can either be client defined, selected by the client from a list of 
categorizations (the list of categorizations being made up of the different categorizations for 
the asset or liability used by the financial service providers), or defined according to a set of 
rules internal to the present invention. For example, this process may be done online (over an 
information network) while the client is connected to the data consolidation network node 
1 00. In another example, the operator may send the client a list of categorizations in a report 
about the clients assets and have the client respond by selecting the appropriate universal 
category definitions. 

Relationship Management 

As stated earlier, the effective management of the relationships and the structure 
between the financial data is an important distinguishing fector of the present invention over 
competitors. Relationship management 244 begins at the subscriber level by defining or 
linking entities to the subscriber then specifying the relationship between the entities 
according to one embodiment of the present invention. When the subscriber is first added by 
the present invention, this relationship structure is defined by either the client or by an 
authorized representative which may include the financial service provider as previously 
discussed in the establishing a new subscriber section of the specification. One embodiment 
of the present invention has no data consolidation done across subscriber boundaries as 
previously specified, however, in an alternative embodiment data consolidation can occur 
across subscriber boundaries. For example, an entity defined for one subscriber (subscriber 
A) may also be linked to a second subscriber (subscriber B) . FIG. 4b illustrates a situation 
where this may arise. The partnership entity 418 which is 75% owned by the family trust 
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parent entity 415 may also show up for another subscriber for whom the r emaining 25% 
ownership is attributed. In the alternative embodiment, the FIG. 4 partnership entity 
ownership can be fully accounted for by two subscribers in the example given above while 
under the originally specified embodiment where no data consolidation occurs across 
subscriber boundaries this would only be possible if all partnership entity owners were 
specified for the current subscriber only. The relationships and the data structure are built by 
the present invention as data is received from the financial service providers. The 
relationships and entities are updated where appropriate as new data is received and 
reconciled with the existing data in the consolidation database. The data structure and nature 
of the relationships has already been specified in the data consoUdation section of this 
specification. 

Accounting Module 

The accounting module 245 is the accounting subsystem of the present invention and 
allows accounting and bookkeeping records to be kept in the consolidation database 230 and 
presented to the client through the reporting module 242 according to one embodiment of the 
present invention. The accounting module may perform standard general ledger 
(bookkeeping) tasks as well as more advanced and customized accounting tracking and 
reporting functions. 

Value Added Services 

In addition to the core services 241, the present invention provides several value 
added services for the client according to one embodiment of the present invention. FIG. 2 
illustrates some of the potential value added services 246 that can be provided according to 
one embodiment of the present invention. Value added services 246 may include 
performance analysis 247, risk analysis 248, and portfolio analysis 249 among others 250 
each of which are briefly discussed below. 

Performance Analysis 

Performance analysis 247 is the comparison of the client's aggregated asset 
performance versus benchmarks or other strategies according to one embodiment of the 
present invention. For example, the performance of a client's equities in total may be 
compared with the an industry benchmark such as the performance of the S&P 500 over the 
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same period of time. Performance analysis may occur in a number of ways including but not 
limited to calculations by asset, asset type, account, or portfolio. The performance analysis 
module 247 of die present invention allows a client to track performance across all his/her 
assets and liabilities and, thus, is more advantageous than the performance analysis 
implemented by a financial service provider that may limit the performance calculations to 
assets and liabilities under their management 

Risk Analysis 

Risk analysis 248 is the calculation of risk factors for the client's aggregated asset 
holdings according to one embodiment of the present invention. Risk values can be assigned 
to all levels of assets and their aggregation. For example, risk may be calculated for an 
individual asset such as stock in XYZ Corporation, a portfolio, an account, and by asset type 
grouping among other calculations. One example of a risk calculation is the beta value, an 
industry standard value representing risk. Though the beta value is widely used in the 
industry, the way in which the beta value is calculated as well as the final beta value 
computed can vary considerably between different financial service providers for the same 
asset The risk analysis module 248 of die present invention allows a client to track risk 
universally across all his/her assets and liabilities, and thus, is more advantageous than risk 
analysis performed locally by a financial service provider. 

Portfolio Analysis 

Portfolio analysis 249 is the analysis of the portfolio investment in terms of where (in 
which assets) and how (by what means or instruments) investments are made and may include 
risk and performance analyses according to one embodiment of the present invention. For 
example, an analysis of securities by industry or by largest holdings are two types of portfolio 
analysis that may be performed by the present invention. Portfolio analysis 249 performed by 
the present invention is similar to the portfolio analysis performed by the financial service 
providers 200 but, however, the present invention can perform portfolio analysis universally 
across multiple financial service providers. The ability to perform portfolio analysis 249 
universally is highly advantageous to the client just like universal risk analysis 248 and 
universal performance analysis 246 are. Conventional portfolio analyses may be performed 
with the distinction that the portfolio analysis is being done across data from several financial 
institutions. For example, portfolio analysis may be done based on the reporting view. 
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According to FIG. 6, this may permit Lorraine 602 to have portfolio analysis done on her 
investment view while the Jones Family Capital Management 608 may have different 
portfolio analysis done on their underlying dat a 

Results Depository Database 

The results depository database 260 maybe one or more separate databases or may be 
partially or fully incorporated into the consolidation database 230 according to various 
embodiments of the present invention. The results depository database 260 contains the 
results of the analyses 240 performed on the client financial data. The types of analyses 
generating results for the results depository database 260 may include the analyses of the core 
services 241 (i.e., reconciliation, reporting module 242, compliance rules 243, relationship 
management 244, and accounting module 245) and the analyses of the value added services 
246 (i.e., performance analysis 247, risk analysis 248, and portfolio analysis 249). The 
structure of the results depository database may change based on the types of value added 
services being performed for the various views of the financial data- 
User Interface and Query Services 

According to one embodiment of the present invention, the client interacts with the 
data aggregation network node 100 using a graphical user interface (GUI) 270 to simplify the 
interaction process. The GUI interface 270 allows the client to access the features mentioned 
herein as well as to retrieve the data contained in the consolidation database 230 and the 
analyses contained in the results depository database 260. The querying services 265 work 
with the GUI interface 270 to allow the client the ability to search his/her data and the related 
analyses. The querying services 265 can work separately from or in conjunction with the 
reporting module 242 to format and present the query results. In alternative embodiments of 
the present invention, non-GUI interfaces may be used. Other embodiments of the present 
invention may link the querying services 265 directly to the reporting module 270, which may 
be responsible for the presentation of all financial data to the client The user interface may 
allow the client to update or add information directly into the system according to one 
embodiment of the present invention. For example, valuation information for non-market 
traded assets such as works of art or collectibles may be added by the client directly into the- 
consolidation database. 
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Subscriber Management System 

In addition to the previously mentioned subscriber data stored in the consolidation 
database 230, subscriber information is also stored in the subscriber management system. 
According to one embodiment of the present invention, the subscriber management system is 
responsible for a wide range of functions related to setting up and maintaining subscribers, 
the principal unit of service, consolidation, and reporting. Even though subscribers enter into 
service contracts with the present invention provider and, thus, are the principal unit of 
service, the participating owners (both individuals and legal entities) of each subscriber are, 
according to one embodiment of the present invention, of greatest interest because they have 
actual ownership of assets and are involved in relationships with one and other that influence 
the manner in which consolidation and reporting is done. The subscriber management system 
stores the information about the subscriber such as contact and agreement information as well 
as the scope of access authorizations already discussed according to one embodiment of the 
present invention. The subscriber management system can be one or more databases or may 
be partially or fully incorporated into the consolidation database according to various 
embodiments of the present invention. The subscriber management system contains 
additional subscriber information including details about the subscriber such as home 
address, billing address, and phone numbers. The subscriber management system may also 
include the permission-based access (scope of access) data necessary for authorizing or 
authenticating the authorization of a client to view particular data according to one 
embodiment of the present invention. This particular subscriber data is used to provide 
clients with permission to access financial data at the various levels mentioned under the data 
consolidation section previously discussed. For example, the subscriber data may let the 
system know that a subscriber does or does not have access to information about an entity, an 
account, a legal entity, an asset or liability, or a position. Permission based access is 
implemented using conventional access control practices for database management systems. 
According to one embodiment of the present invention, a token-based access, control and 
authentication system may be used to supplement the permission-based access previously 
discussed. 
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What is C laim erf Ik: 

1 . A method for aggregating financial data, comprising: 

receiving, from a plurality of financial service providers, financial data 
5 associated with assets of a first user, each of the financial service providers providing a 
respective financial service to the first user; 

determining categories for the financial data; and 

1 0 automatically aggregating the financial data for the first user using the 

categories. 

2. The method according to claim 1 , wherein the receiving step includes electronically 
receiving the financial data from the plurality of financial service providers via electronic data 

15 feeds. 

3. The method according to claim 2, wherein the receiving step includes periodically 
receiving the financial data from the plurality of financial service providers. 

20 4. The method according to claim 1 , wherein the receiving step includes receiving the 
financial data from the plurality of financial service providers via traditional mail. 

5. The method according to claim 4, wherein the receiving step includes periodically 
receiving the financial data from the plurality of financial service providers. 

25 

6. The method according to claim 1, wherein the receiving step includes electronically 
receiving the financial data from the plurality of financial service providers via electronic data 
entry. 

30 7. The method according to claim 6, wherein the receiving step includes periodically 
receiving the financial data from the plurality of financial service providers. 

8. The method according to claim 1, wherein the receiving step includes electronically 
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receiving the financial data from client via electronic data feeds. 

9. The method according to claim 8, wherein the receiving step includes periodically 
receiving the financial data from the client 

5 

1 0. The method according to claim 1 , wherein the receiving step includes receiving the 
financial data from the client via traditional mail. 

1 1 . The method according to claim 10, wherein the receiving step includes periodically 
1 0 receiving the financial data from the client 

12. The method according to claim 1, wherein the receiving step includes electronically 
receiving the financial data from the client via electronic data entry. 

15 13. The method according to claim 12, wherein the receiving step includes periodically 
receiving the financial data from the client 

14. The method according to claim 1, further comprising: 

20 dete rmining a relationship between a second user and the first user, 

determining a respective scope of access for each of the first user and the 
second user, and 

25 providing access to at least some of the financial data for each of the first user 

and the second user based on the respective scope of access and the determined relationship. 

15. The method according to claim 1, wherein the automatically aggregating step includes 
mapping the financial data to the categories. 

30 

16. The method according to claim 1, further comprising: 

storing the financial data in a database. 
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17. The method according to claim 16, wherein the storing step includes storing the financial 
data in a centralized database. 

18. The method according to claim 16, wherein the storing step includes storing the financ ial 
data in a distributed database. 

19. The method according to claim 1, further comprising: 

performing an analysis on the aggregated financial data; and 
receiving a result of the analysis. 

20. The method according to claim 19, wherein the performing step includes performing a 
performance analysis on the aggregated financial data. 

21 . The method according to claim 19, wherein the performing step includes performing a 
risk analysis on the aggregated financial data. 

22. The method according to claim 19, wherein the performing step includes performing a 
portfolio analysis on the aggregated financial data. 

23. The method according to claim 19, wherein the performing step includes performing a 
compliance determination on the aggregated financial da t a. 

24. The method according to claim 19, further comprising: 

storing the result in a database. 

25. The method according to claim 24, wherein the storing step includes storing the result in 
a centralized database. 

26. The method according to claim 24, wherein the storing step includes storing the result in 
a distributed database. 
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27. The method according to claim 19, further comprising: 
' reporting the result 

28. The method according to claim 27, wherein the reporting step includes displaying the 
result on a monitor. 

29. The method according to claim 27, wherein the reporting step includes printing the result 
on a printable medium. 

30. The method according to claim 1, further comprising: 

reporting on the aggregated financial data. 

31. The method according to claim 30, wherein the reporting step includes displaying the 
aggregated financial data on a monitor. 

32. The method according to claim 30, wherein the reporting step includes printing the 
aggregated financial data on a printable medium. 

33. A method for providing financial data, comprising: 

establishing relationships between a plurality of users; 

storing in a database financial data associated with assets of the plurality of 

users; 

determining for each of the plurality of users a respective scope of access; and 

allowing a respective one of the plurality of users access to some of the stored 
financial data based on the respective scope of access and the established relationships. 
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34. The method according to claim 33, further comprising: 
electronically receiving from a plurality of financial service providers the 

financial data; 

determining categories for the received financial data; and 

automatically aggregating the received financial data using the categories; 

1 o wherein the allowing step includes allowing the respective one of the plurality 

of users access to at least some of the aggregated financial data. 

35. The method according to claim 34, wherein the electronically receiving step includes 
electronically receiving the financial data via data feeds. 

15 

36. The method according to claim 35, wherein the electronically receiving step includes 
electronically receiving the financial data on a periodic basis. 

37. The method according to claim 34, wherein the electronically receiving step includes 
20 electronically receiving the financial data via electronic data entry. 

38. The method according to claim 37, wherein the electronically receiving step includes 
electronically receiving the financial data on a periodic basis- 

25 39; The method according to claim 34, wherein the automatically aggregating step includes 
mapping the financial data by the categories. 

40. The method according to claim 33, wherein the storing step includes storing the financial 
data in a centralized database. 

30 

41 . The method according to claim 33, wherein the storing step includes storing the financial 
data in a distributed database. 
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42. The method according to claim 34, further comprising: 



performing an analysis on the aggregated financial data; and 



receiving a result of the analysis. 



43. The method according to claim 42, wherein the performing step includes performing a 



performance analysis on the aggregated financial data. 

44. The method according to claim 42, wherein the performing step includes performing a 
risk analysis on the aggregated financial data. 

45. The method according to claim 42, wherein the performing step includes performing a 
portfolio analysis on the aggregated financial data. 

46. The method according to claim 42, wherein the performing step includes performing a 
compliance determination on the aggregated financial data. 

47. The method according to claim 42, further comprising: 



48. The method according to claim 47, wherein the storing step includes storing the result in 
a centralized database. 

49. The method according to claim 47, wherein the storing step includes storing the result in 
a distributed database. 

50. The method according to claim 42, further comprising: 



storing the result in a database. 



reporting the result. 



5 1 . The method according to claim 50, wherein the reporting step includes displaying the 
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result on a monitor. 

52. The method according to claim 50, wherein the reporting step includes printing the result 
on a printable medium. 

53. The method according to claim 34, further comprising: 

reporting on the aggregated financial data. 

54. The method according to claim 53, wherein the reporting step includes displaying the 
aggregated financial data on a monitor. 

55. Hie method according to claim 54, wherein the reporting step includes printing the 
aggregated financial data on a printable medium. 

56. A set of instructions stored on a medium and adapted to be executed by a processor to 
perform the steps of: 

receiving, from a plurality of financial service providers, financial data 
associated with assets of a first user, each of the financial service providers providing a 
respective financial service to the first user; 

determining categories for the financial data; and 

automatically aggregating the financial data for the first user using the 

categories. 

57. A set of instructions stored on a medium and adapted to be executed by a processor to 
perform the steps of: 

receiving, from a plurality of financial service providers, financial data 
associated with assets of a first user, each of the financial service providers providing a 
respective financial service to the first user; 
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determining categories for the financial data; 



1 automatically aggregating the financial data for the first user using the 

categories; 



determining a respective scope of access for each of the first user and the 
second user; and 

providing access to at least some of the financial data for each of the first user 
and the second user based on the respective scope of access and the determined relationship. 

58. A set of instructions stored on a medium and adapted to be executed by a processor to 
perform the steps of: 

receiving, from a plurality of financial service providers, financial data 
associated with assets of a first user, each of the financial service providers providing a 
respective financial service to the first user; 



automatically aggregating the financial data for the first user using the 

categories; and 



59. A set of instructions stored on a medium and adapted to be executed by a processor to 
perform the steps of: 

receiving, from a plurality of financial service providers, financial data 
associated with assets of a first user, each of the financial service providers providing a 
respective financial service to the first user; 



determining a relationship between a second user and the first user; 



determining categories for the financial data; 



storing the financial data in a database. 
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determining categories for the financial data; 

automatically aggregating the financial data for the first user using the 

categories; 

performing an analysis on the aggregated financial data; and 
receiving a result of the analysis. 

60. A set of instructions stored on a medium and adapted to be executed by a processor to 
perform the steps of: 

receiving, from a plurality of financial service providers, financial data 
associated with assets of a first user, each of the financial service providers providing a 
respective financial service to the first user, 

detennining categories for the financial data; 

automatically aggregating the financial data for the first user using the 

categories; and 

reporting on the aggregated financial data. 

61 . A set of instructions stored on a medium and adapted to be executed by a processor to 
perform the steps of: . 

establishing relationships between a plurality of users; 

storing in a database financial data associated with assets of the plurality of 



users; 



determining for each of the plurality of users a respective scope of access; and 
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allowing a respective one of the plurality of users access to some of the stored 
financial data based on the respective scope of access and the established relationships. 

62. A set of instructions stored on a medium and adapted to be executed by a processor to 
perform the steps of: 

establishing relationships between a plurality of users; 

storing in a database financial data associated with assets of the plurality* of 

users; 

determining for each of the plurality of users a respective scope of access; 

allowing a respective one of the plurality of users access to some of the stored 
financial data based on the respective scope of access and the established relationships; 

electronically receiving from a plurality of financial service providers the 

financial data; 

determining categories for the received financial data; and 

automatically aggrega ting the received financial data using the categories; 

wherein the allowing step includes allowing the respective one of the plurality 
of users access to at least some of the aggregated financial data.* 
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